The Internet was launched over thirty years ago. Many advances in technology have ensued and many applications have evolved, and yet some technologies have change very little over the years. Today, e-mail is the primary means of communication between users of the Internet. While augmented by instant messaging, the fundamental technologies have changed little. Moreover, files are stilled shared using the file transfer protocol (“FTP”) or as attachments to electronic mail. Users receive little information about the files that are sent to them or which they download. Where file sharing is part of a collaborative effort among a number of authors, it is important that participants in that effort know the file “status”, which includes when the file was last changed, what was changed, who made the changes, and who has knowledge of the changes. Additional information useful to participants in the collaborative effort includes the evolution of the file and statistics on resources used to create the file at each point in its evolution. The file transfer systems currently in use today either do not provide the file status or file history in any meaningful detail or require that file transfer functions utilize a central server accessible by all participants in the collaborative effort.
One approach to collaboration is by using an Internet-based web server. Various server-based offerings were implemented in the early days of the Internet. Some of these programs combined address books, bulletin board, file sharing, discussions, project management, and other typical collaboration tools together into a hosted solution.
Hosted solutions were viewed has having the great advantage of not requiring IT installation and support while easily supporting communications between people at different companies behind firewalls. However, hosted solutions never became prevalent for a variety of reasons. One of the problems was that of scale. Since all of the users were required to connect to the same servers, the maximum number of users that service could handle was limited by the computing power of the servers used. Yahoo serves as a case in point. During the growth of the Internet in the 1990s, it spent virtually all of its computing resources ensuring that response time was acceptable for the growing number of users of the Internet.
Another problem with the hosted solutions is the location of the intellectual property. The hosted systems require that a participant's documents (intellectual property) be placed on a third party's server, thus raising significant policy questions for participants. Similarly, that intellectual capital may not really be preserved in the long run because it cannot be moved inside the organization.
Some of the hosted solutions offer sales of their servers to enterprises. While that sometimes provides a good Intranet solution, it places the organization in the same business as the hosted provider and requires that they make their collaborative servers accessible on the Internet for any work between organizations. It also creates a single point of failure—if the collaboration server fails, all of the data is inaccessible until the server is restored from backup.
A second approach based on peer-to peer (P2P) technology emerged in 2000. Groove Networks, Endeavors Technology, Roku, and others created a means for sharing information without requiring that all information be saved on a central, hosted server. These companies focused on direct connections between individual client systems and offered either access to files or replication of files. Each of these companies created a switch of sorts—a system that clients could connect to using an outbound connection and then routed requests between connected systems. This is virtually identical to the way that Instant Messaging services provided by Yahoo and AOL work.
While these solutions resolved many of the problems caused by firewalls, the solutions had problems of their own. First, scale again is an issue—none of the solutions focus on scale—their primary concern is functionality rather than building huge switches. In contrast, the reason that AOL Instant Messenger and Yahoo Instant Messenger work is because their functionality is trivial and the bulk of the computing resources are applied to providing enough computer power to move messages between users with a minimum of latency. In order to make a technology like Groove or Endeavors work, the company would have to virtually dedicate itself to making fast switches.
Further, client computers systems do not have the same operational characteristics that servers do. They are often turned off on a regular basis. They may not ever have the same IP address or may shift from network to network. They will also have varying bandwidth. Mobile users may have high speed Internet at the office but dial-up from the road. The performance of direct connections between systems, then, is often problematic.
There have been several efforts relating to data synchronization and transport between systems, including efforts that deal with high latency connections. A UCLA project called Ficus involved file replication within a LAN environment. This was implemented through a file system layer within Unix, requiring kernel modifications, and thus being dependent on the specific version of Unix. Trusted Information Systems and UCLA married the security aspects with the file sharing of Ficus into a later project called Truffles. This eventually evolved from its kernel level implementation to a user level, background process implementation, initially called Rumor and ultimately (with the security pieces) called User Level Truffles (ULT). Truffles/Ficus used a connection-oriented protocol to move information instead of the store and forward messaging infrastructure. Several other replication projects exist, including rsync, which focus on replication in both high and low bandwidth environments. None use the messaging infrastructure as a channel for data transmission, but some of these systems offer techniques for synchronization.
Another approach is taught by PCT Application WO 01/16804 filed by Chandhock et al. entitled “Maintaining Synchronization in a Virtual Workspace” (herein, Chandhock). Chandhock teaches the sharing of files among members of a workgroup via email messages that include a synchronization command in the embedded in the multipurpose Internet mail extension (MIME) of the email header and a MIME file attachment. Upon detection of an add or update synchronization command in a message from a group member, a user agent will determine whether a local copy the MIME file attachment resides on the recipient's computer. If a local copy of the attached file exists, the user agent makes a backup copy of the local file and saves it to a specified directory, then replaces the recipient's copy of the attached file with the sender's copy. According to Chandhock, files may be shared and synchronized in this way among group members.
Implicit in the approach taken by Chandhock and other is that synchronization of shared files among members of a group is achievable. In this context, “synchronization” means the sharing of a file that is believed by members of the group to be the same file. When a member of the group makes a change to the file, the changed file is conveyed to all other members and the changed file replaces previous versions of the file as stored by the other group members. In a “synchronized” environment, there is only one file,and all members are believed to possess it.
If this definition is what is meant by synchronization, then true synchronization may be unattainable. In a group of three or more members, it becomes increasingly difficult to be confident that a file possessed by one member is the latest version. Members may make changes and exchange files at approximately the same time resulting in multiple versions of the file to exist at the same time. This is not synchronicity.
Applicant, in previous writings it used the term “synchronizing” to describe the behavior of Applicant's system, which was not really a synchronizing files at all. In fact, Applicant's system was in reality a data “replication” system and method. “Replication” in this context refers to the copying of a version of a file from one member's system to the system of all other members of a group without requiring that existing versions of that file be replaced. Accordingly, in this application Applicant has adopted a lexicon that describes a process of file exchange in terms of “replicating” files among group members.
What would be particularly useful is a system and method for the formation of groups, each member of which is trustworthy, and for the secure replication of information among members of the group without the need for a central server. The system and method would additionally permit participating members to determine the most current information in the possession of that member.